1. Technical Field
The invention relates to service management and service presentation systems, wherein measurement data regarding services delivered by Service Providers to customers are gathered and handled to compute and communicate service indicators defined in Service Level agreements and, in particular, relates to adjudication means for adjudicating any type of measurement data in a system managing the Service Levels provided by Service Providers.
2. Related Art
A Service Provider (SP) provides or manages resources for its customers. A resource can be a server, a particular application on a server, a networking device, people in a help desk to answer users, people to fix problems, people to manage and change systems configuration and location, . . . etc. . . . or a complex solution made of multiple elements to accomplish or support a customer business process. The Service Provider and the customer can be different firms, or different departments in a large global enterprise where departments are organized as support services for other departments, e.g. Marketing, Research, Sales, Production, . . . .
Normally, a Service Level Agreement (SLA) is signed between a provider and a customer to define the role of each party and to remove any ambiguity from the business relationship.
Such a SLA:                Identifies the parties involved in the agreement.        Describes the service to be provided, and identifies in a measurable and quantifiable manner indicators of the quality of the service on which obligations will be set, with a possible series of exceptions and stipulations in the way to calculate these indicators.        Defines the obligations, called Service Levels (SLs), to be met on the identified indicators, so that the expected quality of the delivered services is set in an un-ambiguous manner.        Defines the agreement period for which these obligations are set forward.        Pre-defines penalties to be paid/executed by the SP if the commitment(s) is (are) not met. If a commitment is exceeded, a reward can also be predefined, to be paid by the customer.        Also defines reporting policies, corrective actions, dispute resolution procedures, termination criteria, intellectual property . . . .        
A SLA is encountered when considering utilities to be trusted “always-on” services such as providing water, electricity, gas, telephone, e-service (e.g., e-Business On Demand), etc. In fact, a SLA exists when a specific service offer including commitments is engaged with a customer.
By itself, a SLA does not bring any change in the level of service delivered. The Service Provider and/or the customer need to implement a Service Level Management (SLM) program that will actually result in higher levels of services. Indeed, a SLA only specifies the agreed criteria for determining whether or not a set of agreed service quality levels are met. When not met, the issue is to determine what caused the violation, maybe how to improve the service, or change the SLA or the provider. The Service Level Management begins with the development of new service levels for a new contract and continues throughout the life of the contract to ensure Service Level commitments are met and maintained.
The Service Level Management is commonly identified as the activities of:                negotiating, identifying and agreeing the measurable services that support the Business Process of a customer, and defining the SLA articulation in an offering for service with Service Level Objectives (SLO) also known as Service Level Targets (SLT),        monitoring resources used to deliver a service and capturing data on how well these resources perform from monitors or from logs,        calculating intermediate and high level Service Levels results or scores using the predefined service parameters formulae (called metrics) and taking into account all kinds of exceptions that can occur, assessing attainment versus commitments and possible penalties or rewards,        assessing impact of operational outages or degradations in terms of SLAs (services) and financial impacts, alerting in real-time of possible or effected outages, diagnosing problems for resolution, enforcing corrective actions wherever possible to regulate the delivery system and therefore try to proactively guarantee the achievement of obligations,        reporting to the provider and the customer on real numbers versus contractual numbers, and sealing final numbers to be used for rebates or rewards,        rebating to customers when commitments are not achieved, or rewarding the provider when commitments are exceeded, and        refining, improving and reviewing SLA definitions, Service Levels and services that support the customer's Business Process.        
Today, there are SLA Management Systems which are automated for managing SLAs such as IBM Tivoli Service Level Advisor, Computer Associates SLM, Digital Fuel or InfoVista. They are built to accomplish, at least, a minimum set of tasks such as capturing data from monitoring systems, and they participate or supply information to other service management activities such as alerting, enforcing or reporting.
Some of these systems are sufficiently elaborated to solve the problem of accounting for such situations where an SLA is violated due to Customer's responsibility. In such cases, the result must be revised to reflect the true responsibility of the Service Provider after calculation by these systems. Indeed, very often a piece of the solution used to support the customer business process which is managed by the Service Provider is coming from the customer, or is under the customer's responsibility (shared or not with the Service Provider). This activity will be called Adjudication in the following, and the information input to this activity will be called Adjudication Elements.
However, these systems either enable adjudication through direct modification of data, or employ means specific to each case of adjudication. In the first case, this does not allow to define the adjudication to be applied before all the data to be adjudicated are in the system. The second case corresponds to numerous specific cases depending on the types of data and the situations. Standard ways of doing these cases use adjudication elements specifying modifications for each data points, which can be quite heavy to manage and to use with data feeds like periodical response time measurements containing numerous data points in a SL period (i.e., business period). Or they involve code and data structures specific to each measurement domain and adjudication situation and this creates a significant code maintenance problem and a development bottleneck when new domains or situations arise.
Therefore, there is a need for a universal method describing adjudications in order to avoid complex development and information management in those systems, and to allow a quick and efficient creation of modifications for a large amount of data. And yet, this method must allow more optimal and less generic ways of describing and processing adjudication elements to co-exist and to be developed in parallel, and also to be used for specific cases when they are more appropriate.